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Wni ectinn U ndpr-^j; U.S.C. 112 . 

Claims 1-19 are rejected under 35 U S.C. 112. second paragraph, as heme 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. ITie Office Action states that the phrase "may be" 
renders the claim indefinite because it is unclear whether the limitations following the 
phrase are part of the claimed invention. 

Applicants i^spectfully traverse this gmond of rejection for the following reason. 

Applicants note that the words following "may be" are not much limitations of 
the claimed invention but are intended as merely descriptive of a conventional element 
that may, but need not. exist within an IP data payload. As such, the "may be" language 
is an accurate characterization of the IP data payload. Furthermore, as will be explained 
m moie detail hcreinbelow, whether the IP data payload contains the conventional 

element, is irrelevant. 

More specifically, claim 1 states "the contents of said IP data payload of said IP 
packet exclusive of any information in any real time protocol (RTF) header which may be 
therein" Thus, the actual phrase of interest for the claim is "a^iy real time protocol (RTP) 
header which may be therein" in its entirety, r.lher than simply the word "therein" which 
follows the words "may be". This phrase characterizes an RfP header, which ,s the 
conventional element that may, or may not, be within the IP data payload of any particular 
IP packet. 

A careful reading of the claim reveals if the IP data payload does not contain an 
RTP header, then of course, it cannot be employed in the step of identifying, since it is 
not there. Likewise, if on RTP header ,s included in the IP data payload. then it is not 
employed in the step of identifying, because the claim language excludes it from use. So. 
whether or not an RTP header is present in the IP data payload, the result is the same, i.e., 
no use is made in the identifying step of any information in any RTP header which might 

be in the IP data payload. 

Tlxus. the claim language is defmite, nolwitlistanding the present of Ihe term "may 
be" indeed the definite meaning of the claim would be readily apparent to one of 
ordinary skill ix, the art. In support of this notion, applicants note that the European 
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counterpart to this application has issued in Groat Britain, France and Germany (1 175098, 
1175098. 60100204.0) with a very similar claim 1 that has the same phrase "may be' as 
follows: 

A method for processing an internet protocol (TP) pnxikct (101, 
111), comprising tlie step of identllying tliat said packet contams motion 
niclire expert group (MPEG)-2 video as a function of only ihc contents of 
s^S daS paylo^ (HI) of «aid IP packet e.clvusive of ar.y mformm.on 
?n any .^al time protocol (RTP) header which may be w,thm said IP data 
payload. 

Claims 1-6, 20-21, 26-27, 31, 34-36. and 40-43 are rejected under ^5 U.S.C. 
102(e) as being anticipated by United States Patent No. 6,557,031 issued to Mimura et al. 
on April 29, 2003. 

The Office Action slates that Mimura el ai. teaches all the limitations of the 
rejected claims. 

This ground of rejection is traversed l or the following rea.sons. 
Although the Office Action maintains its previous grounds of rejection, applicants 
believe the Office Action continues to misconstrue certain as^pccts of Mimura et al., as 
well as certain elements of applicants' previous response. Therefore, applicants repeat 
their previous response, and clarify it with additional comments regarding the Office 
Action's statements in response thereto as follows. 

As a general note, it appears that Mimura et al. detenriincs that the IP packets 
contain MPEG video based on techniques that do not render applicants' invention 
obvious. Mote sp^ifically. it appears that in Mimura et al. an IP packet is known to 
eontain video based on address infonnation. This can be seen, for example, from column 
4 lines 52 through column 6, line 47, in which it is oft repeated that Min.ura et al. assigns 
a'correspondence from the IP address of the IP packets containing video to a PTD value, 
which is the 13-bit packet identifiers which come after the synchronization byie m the 
MPEG video transport stream (JS), which is u.sed then used to route the TS video in the 
MPEG video network, e.g., a cable television or satcMiie system, in other words, it seems 
that in Mimura et al. that IP packets that contain MPEG v.deo are identified based on 
information in the IP header, namely, an address, and ihcn the PID is assigned or 
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associated therewith. Such a determitiation i. not based on the IP data payload of an IP 
packet, nor is there any searching of the IP data pay.oad, as required by various ones of 
applicants' claims. 

Turning now to the specifics of applicants' previously presented arguments and 
the Office Action's response thereto, the first argument has been mischanictcrized by the 
Office Action. Applicants did not argue that Mimura et al. docs not disclose that the IP 
packets do not come out from the sources because MPEG-TS packets are not IP packets, 
as was asserted by the Office Action. 

Instead, applicants pointed out tlwt their invention is only directed to IdentifyinR 
those IP packets that contain video. Thus, aU of the sections of Minmra el al. cited by the 
Office Action, such as column 2. lines 29-54, that relate to placing into an IP packet 
MPEG video from a known MPEG video source, e.g.. video received from a cable 
television or satellite system, are totally irrelevant to applicants' invention. -ITiis is 
because - V^^^ ^" that rnn com, out from n Vno.vn MPF,0 video source is 

MPEG video . Therefore, there is no need to examine the content of .och a packet. 
Instead, that such a packet contains MPEG video is already known, .since the packet came 

from an MPEG video source. 

Additionally, applicants previously pointed out Uiat 11' packets do not come out 
from the MPEG sources. This is because MPEG Transport stream (TS) packets are m 
IP packets. So any processing in Mimura et al. of TS packets is excluded from the soopc 
of applicants' claims, even if it were to use the same techniques disclosed by applicants, 

which, in any event, is not the case. 

In response, the Office Action suggests that the IP packets arc used in the Internet 
instead of the MPEG-TS packets, and thus Mur^ara ct a), indirectly discloses that the IP 
. packets come out from the sources. However, in contract to applicants' invention. 
Mimura et al. never suggests how to ,lrt.rtfrnm .h. p.yloHd of nn IP packet that the IP 
packet contains video. Instead, Mimura et al. simply assumes or knows, perhaps from the 
address information, that packets headed for CATV Network via an intemctworkmg unit 
contain MPEG video. This can be seen from the fact tl.at in column 12, lines 49-50, it 
states that the "video transmission is made toward the CAIV network from the server 
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connected to the IP network" Thus, all tliai is disclosed by Mimura ct al. is how to 
convert the datn contents of IP packets that are already known to be N4FEG video data in 
MPEG video signal (PES) format into an MPEG-TS signtJ format. 

Since, without examination of their IP data payload the IP packets arc of Minr,ura 
et al. are already known to be MPEG video dalu, Mimura et al. does not leach or suggest 
a step of identifying that a packet contains motion picture expert group (MPr.G).2 video 
as a fiinction of only the contents of Ihe IP data payload of the 11' packet exclusive of any 
information in any real time protocol (RTP) header, as required by applicants' claims. 
Thus, Mimura el al. does nol leach applicants' invention. 

' Regarding applicants' second argument, the Office Acti.m states that Mimum et 
al. teaches all tlie limitations of applicants' claims 20-21, 31, 34-36. 40-43. However, the 
section of Mimura et al. cited in support of this position is mu explained by the Office 
Action, nor is it explained how such section teaches applicants' claimed invention. 
Instead, the Office Action simply repeats some of applicants' claim language and states 
that column 9, line 5 to column 12. line 15 of Mimura et al. teach the recitations of that 
claim language. Such a statement is a gross misctoterization of the teachings of the 

cited sections of Mimuia et al. 

Notwithstanding the Office Action's assertion to the contraiy, as previously 
indicated, the sections of Mimura cited by the Office Action do not leach searching 
through the IP data payload of an IP packet for a pattern. >^or <io they .each indicatmg 
lhat a packet contains MPEG video only when the pattern i.. found. Moreover, the cited 
section Of Mimura does not teach determining whether a payload of an IP packet has a 
length equal to an integral multiple of the length of an MPEG.2 tiran-sport stream packet. 
In actuality, tiie cited section deals with fonmog ^ MPEG Iransport stream 
. packet that includes IP header infom^ation. Note that this is son of the opposite ftmction 
from that which requires applicants' invention. 

No searching of IP packets is done for this purpose, and in fuct IP pnckcts donll 
even exist. Moreover, when, in the cited section, MPEG video in IP packets is to be 
extracted for conversion to transporl stream packets, Ihcre is M searching involved. In 
ti.e cited section it is, as previously explained, assumed ihat Ihe TP packets are known to 
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contain video. Instead, as explained in subsequent sections of Mimura et aJ., as well as 
column 4, lines 52 thrcueh column 6, line 47, this knowledge appears to be ba-sed on the 
IP header information of the IP packet, and is not based , as required by applicants- 
claims, onjiecontent of the data payload of the IP packet, which seems to only contain 

MPEG video in PES format. 

n,us, there is no teaching or suggestion in Mimura et al. to determine ihat an IP 
packet contains MPEG.2 data based solely on the TP data payload. exclu-sivc of any RTP 
header therein. 

Regarding claim 27, applicants' renew tlieir third argument that the cited section 
of Mimura et al. i.e.. column 9, line 43 through column 10, line 11, docs not teach 
processing the IP packet with a priority assigned for packets containing video when the 
indicating step indicates that the IP packet contains video. The word priority does not 
appear anywhere in that section. Nor are there any synonyms for the word priority. 
Likewise, there are no words suggestive of the concept of priority anywhere in that 
section. Moreover, there is no suggestion of any other types of packets that might have a 
different priority than the video-containing packets. 

Of course, the forgoing is the natural rcsuh of the fact thai the cited section of 
Mimura et al. is plated to the formation of MPEG-TS signals which include IP header 
information, fhus. there are no actual IP packets at this point, and consequently there 
cannot be any processing of IP packets, let alone processing of IP packet., with different 
levels of priority. Also, the cited section does not have an IP packet that was identified as 
having video based on only the IP data payload, because there was n» identification of IP 
packets. 

Applicants remind the Examiner that their claims as cuircntly presented cleariy 
exclude any information in the RTP header Crom being considered in determining 
whether an MPEG video signal is present or not Thus, only non-header infonnatmn of 
any type is searched and used to detennine the presence of MPEG video. 
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Conclusion 

It is tespcctfaUy submitted that the Omce Action's rejccl.oiis have been overcome 
and that this appHcatioa is now in condition for allowance. Reconsideration and 
allowance are, therefore, respectfully solicited . 

If. however, the Examiner still believes tliat there arc unresolved issues, he is 
invited to call applicant's attorney so that arrangements may be made to discuss and 

resolve any such issues. 

In the event that an extension of iime is required for thi.. amendment to be 
considered timely, and a petition therefor does not otherwise accompany this an.endmenl, 
any necessary extension of time is hereby petitioned for, .ad .he Commissioner .s 
authorized to charge the appropriate cost of such petition to the Lucent Tcchnolagics 
Deposit Account No- 12-2325, 



Respeclfiilly. 



J. P. Hcam 
K.N. Matthews 
C.C. Yu 




Eug^ J. RogentliaU Attorney 
RegflNo. 36,658 
732-949-1857 



Lucent Technologies Inc. 
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